The Session Initiation Protocol (SIP) is a protocol for creating, modifying, and terminating computer network-based communication sessions, such as for an Internet-based telephone call between two or more participants. An individual SIP-based communication session is often referred to as a SIP Session and can be managed by a SIP application server running a SIP container that manages the SIP signaling. Multiple SIP sessions may be related to each other according to application logic, such as in a conferencing application, and may thus be thought of as being part of a single logical entity, which may be referred to as a SIP application session.
In a SIP application server, multiple SIP application sessions are managed by the SIP container. In large computer network-based communications environments capable of managing hundreds or thousands of individual SIP application sessions, a clustered architecture is often employed, where a cluster of SIP application server nodes, each node running an instance of a SIP application server, communicate with SIP clients via a SIP proxy. The SIP proxy routes SIP communications belonging to any given SIP application session from the SIP client to the appropriate SIP application server node that manages the SIP application session. This role performed by the SIP proxy is referred to as “maintaining SIP session affinity” and is typically used in cluster architectures where SIP application sessions are not kept in a central data layer that all SIP servers can access so as to maintain better cluster performance in the form of better throughput per node.
Ideally, all events related to a specific SIP application session should be invoked at a single SIP application server that manages the SIP application session, whereupon the SIP application server performs event-related tasks. However, in some situations an event is invoked at a SIP application server in a cluster that affects the state of a SIP application session that is managed by another SIP application server in the cluster. Examples of such events include non-SIP container events such as the receipt of a non-SIP protocol message that was delivered to the server not via the SIP proxy and its per-application session distribution mechanism, or a non-SIP application timer execution event. These events may require modifying aspects of a SIP session that is handled by another server in the cluster. When this occurs, it is imperative that the SIP application server that manages the SIP application session, and not the server where the event is invoked, perform the event-related tasks.